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PACS integration means different things to different people. One can distinguish between seven 
different levels of integration, ranging from No Integration up to API Level Integration. The current 
trend seems to gravitate towards the use of messaging standards (e.g. DICOM) and integration 
profiles (e.g. IHE). All integration levels have their advantages and disadvantages. 

1 . Introduction 

When people think about PACS integration, they typically seem to relate it to the type of integration that is 
covered by Integrating the Healthcare Enterprise (IHE) effort [IHE] , Integration means different things to 
different people. 

Some vendors claim that their system is seamlessly integrated, only to find upon closer inspection that they 
indeed use interface boxes, or conversion software between the systems. Other applications are totally 
integrated. A claim by a vendor that they support DICOM flMEMAI doesn't necessarily mean that the system can 
be integrated into a PACS. 

This whitepaper discusses the different levels of integration, their advantages and disadvantages, the role of 
standards, and current trends. 

2. Levels of System Integration 

Within a PACS system one can distinguish six levels of integration (and one level of non-integration): 

• Level 1: API Level Integration 

• Level 2: Procedure-Call Integration 

• Level 3: Messaging Integration 

• Level 4: Integration Profiles 

• Level 5: Context Integration 

• Level 6: Physical Integration 

• (Level 7: No Integration) 

2.1 Level 1; API Level integration 

This type of integration resides on a computer, and links two software applications. It is called API (Application 
level Programming Interface) level integration because the interface consists of a well-documented software 
library. 

A good example of this interface is a scheduling application/database that talks with a DICOM Toolkit software 
package, to provide a DICOM Modality Worklist, which contains a schedule for a particular modality. This is the 
tightest integration level possible. 

2.2 Level 2: Procedure-Call integration 

In this case, an application on a device, issues a remote procedure call, or a standard command such as a SQL 
(Structured Query Language) to another application. An example is a PACS workstation, issuing a SQL query, to 
a PACS archive having an Oracle database, requesting a list of the studies for a particular patient including study 
date, modality type, and number of images, displayed in a mini-image (postage stamp) directory for a physician. 

This is a rather tight integration because the workstation must know the exact database scheme, and supported 
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record in order to be successful. Except for the fact that SQL is an ANSI accredited, standard database 
language, the user must know a lot of information about the particular software product, requiring intimate 
knowledge of the vendors' specifications. 

2.3 Leva! 3: Messaging Integration 

This level of integration is probably most familiar to people. It is achieved by using standard messaging, and 
protocols between applications, such as DICOM for imaging; or HL7 for patient demographics, orders, and 
results. 

An example is the usage of an HL7 order message from an order entry application to a scheduling system. In 
principle, vendor A, providing the order entry software, does not need to know anything about the specifics of 
the scheduling software provided by vendor B, but must know sufficient detail about what type of HL7 message 
it supports. 



Users increasingly want their PACS 
system and workflow manager to 
support DICOM services with the 
same functionality as they provide 
to their other products sold by the 
same vendor. 

For example, DICOM just 
standardized the general purpose 
Worklist service whereby 
workstations can access the list of 
exams to be read, update the 
reporting status, and exchange 
information about the data needed 
for the reporting. 

Supporting messaging standards 
alone is not sufficient. Efforts are 
being made to define additional 
profiles such as defined by IHE, 
and to require vendors to support 
these. 




Figure 1. Levels of integration 



Unfortunately, there is a lot of variation in HL7 messaging, often requiring the usage of interface engines to map 
certain HL7 attributes to those required by the receiver. The good news is that ongoing conformance activities 
within the HL7 standardization are addressing this, and the new version of HL7 3.0 it is much tighter defined. 

DICOM messaging is better defined, and DICOM-compatible devices require a conformance statement, which 
exactly defines, in a pre-described format, the services, and messaging content. 

2.4 Level 4: Integration Profiles 



Just supporting a messaging standard is not sufficient: the definition of standard "profiles", defining a specific 
subset of the standard is required to enable seamless integration. 

An example of this integration is the usage of a DICOM Modality Worklist and Performed Procedure Step to 
exchange patient demographics, and scheduling information from a scheduling system to a modality such as a 
CT or MRI, and image management information to the PACS. 

The IHE integration profile specifies exactly which attributes, i.e. information should be exchanged, the timing of 
a service in relationship with other DICOM services, and even mapping between different standards, i.e. DICOM 
and HL7 messaging. 

2.5 Level 5: Context Integration 

This level is similar to the previous one. One could actually argue that it is the same, because two applications 
also exchange messaging. However, the applications by themselves are more disjoint than when using 
standards such as DICOM or HL7. 

An example is a physician workstation that runs multiple applications, such as an image viewer, a viewer to 
display EKGs, and one that displays lab results. The information exchanged among these applications is limited 
to their context information. 

A "context manager" functions as an intermediary, passing any context changes between applications. For 
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example, as soon as a physician switches from Mr. John Smith to Mrs. Jones on the image viewing directory, the 
application signals the context change to the context manager which passes it to the other application so it also 
automatically displays the EKG, and lab tests for Mrs. Jones. 

As with Messaging Integration, vendor A, who provides the imaging software, does not require knowledge of the 
lab, or EKG system from Vendor B, but can use the information exchange as defined by the CCOW (Clinical 
Context Object Working group) standard. 

CCOW is not only a blessing for a user who wants to integrate different 
applications on a single desktop, it also enables vendors who are 
consolidating to offer software packages that were developed by different 
companies, to show a somewhat integrated view. 

2.6 Level 6: Physical Integration 

This level integrates the physical hardware, typically only sharing the 
operating system that run the applications. This type of integration is 
critical in many departments due to space and power restrictions. 

With the increase in computing power, memory and disk capacity, there is 
rarely a reason to have more than one computer monitor at a worksite. A 
good example is a dictation system using speech recognition, which until 
recently required its own processor, but can currently run on the same 
platform as a viewing station. 

2.7 Level 7: No integration 

One might wonder why this is even defined as a level at all. The reason is, 
to highlight these occurrences, and make the user aware of these so he 
can work with a vendor to start the migration of these systems to a higher 
level of integration. 

It is unfortunately not uncommon to see more than one monitor and/or 
computer on a physician's desk. As a minimum, some level of physical 
integration would prove beneficial. 

3. Advantages and Disadvantages 

Advantages and Disadvantages of the Different Integration Levels include: 

• Reliability: As a general rule, the tighter the integration, the higher the reliability. 

For example, a Radiology Information System (RIS) passes scheduling information in the form of an HL7 
message to an interface box (commonly known as "broker"). The box then serves modalities requesting a 
DICOM Modality Worklist for their daily exam schedule. 

Compare this to a RIS that has an API to a DICOM application that provides the Worklist directly to the 
modality, without having an extra to perform HL7 to DICOM mapping. There is no question that scenario 
two is more reliable because yet another box increases the chance for hardware failure. 

• Single Point of Failure: A tightly integrated system, consisting of relatively few components is risky 
because if one part goes down, more of the features and functions are affected. 

Imagine a single image manager/archive that serves all of radiology, the physicians in their offices, as 
well as the radiologists that read the images from their home. If for some reason this system goes down, 
no-one has access to any images. In contrast, if an institution provides a web server in addition to the 
image archive, a physician can still view images from their office, or home even if the main archive is 
down. 

One could argue however that the same level of availability can be achieved by a tightly integrated 
system, e.g. by having a dual processor, back-up storage, hot swappable drives, etc. However, it is 
necessary to make sure that the architecture allows for this, and that the system is configured 
accordingly. Given the option, most customers are tempted to purchase more workstations, or other 
additional features, instead of, for example, a dual database archive/server for system backup. 

• Cost: This is difficult to assess, as there does not seem to be an increased cost when purchasing a tightly 
integrated system from a vendor. 

One of the advantages of a more loosely connected system is that it allows for using components such as 
monitors, and workstations from different vendors. This could provide cost savings, however, the cost of 
testing, and integrating foreign components increases. 



What is the role of standards in 
these different levels of 
integration? 

Without the messaging and 
profile-level integration, the 
communication between 
Information Systems and 
Modalities, Workstations and other 
PACS components would all be 
proprietary. 

For example, Japan, has a lower 
penetration of DICOM for PACS, 
because many vendors provide 
complete systems that are tightly 
integrated which hospitals seem 
perfectly happy with. 

Similar situations exist in Europe, 
where in some countries the 
institution by default purchases 
from one single (usually domestic) 
vendor. 
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4, Conclusions 

What is the current trend? As shown in the Figure below, the integration seems to gravitate to the center levels, 
i.e. towards the messaging and profiling levels (levels 3 and 4), and from physical integration to context 
integration (level 6 to level 5). 




fl% i * 2 3 4 5 6 

Figure 2 Trend* nP ^ int citation 



The push to context integration (level 5) is caused by: 

• the need to provide physical integration for the different applications that are currently running on 
different platforms, and for different applications to exchange context information; 

• institutions that understand the importance of integration, and are starting to require all their applications 
to support CCOW. 

The ultimate goal of integration is to facilitate an Electronic Health Record (EHR) whereby a user can access the 
complete patient record from a single location, which today is typically a terminal, but tomorrow may be by 
wireless PDA. This will allow a physician to be able to assess a patient from an integrated view, having access to 
not only lab tests, but also dental records, diagnostic images, previous reports, etc. This fits the trend that 
physicians are starting to look at a patient as a whole whereby realizing that an infected tooth can cause a 
headache, impact the person's laboratory result, or even affect vision and hearing. The support of standards and 
the converging of the different integration levels to profiles is critical to make this happen. 

5. References 

[IHE] "IHE Radiology Technical Framework", http://vvvvvv.ihe.net 

[NEMA] "Digital Imaging and Communications in Medicine", http://rnedical.nema.org 

[OTech] http :// www.QTechi mq . com/ 



About Ringholm GmbH 
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